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Preface to Version 1.2 

The latest Federal Modality Vendor Workshop held on May 5, 1999 resulted in several comments, 
but none of them was as important as the suggestion from IHE that the VA synchronize its 
requirements with the IHE requirements. In that spirit the VA team undertook the restructuring of 
this document. The main requirements of this document are now organized around the Actor Role 
definitions set forth by IHE for the acquisition devices. 

This document retains some of its original structure to provide context to the VA specific 
requirements. These are requirements not explicitly defined by IHE but vital to the proper operation 
of the VA imaging system. 

Other specific changes are detailed in the change log of this preface. 

Changes for Version 1.2 

This list of changes is included to easily identify sections and paragraphs changed from the 
previous version. The nature of the change is identified in the accompanying note: 

1. The Domain of this specification (section 4) is changed to reflect the relation of this 
specification to the IHE Technical Version 3.0 document. 

2. The section describing the Hierarchical Integrated Data Model has changed to include a 
modified IHE data consistency model diagram. 

3. Section 6.1 (Process steps) is now replacing the section formerly titled “Sequencing” 

4. The individual process steps are labeled to reflect their relationship with the IHE process steps. 

5. Since IHE makes no distinction between the creation and the ipdate of the MPPS record, we 
eliminated the Modality Performed Procedure Step Updated event. We also combined the 
Storage and Storage Commitment steps. 

6. The section “AE Specifications” is moved after ‘Association Acceptance Policies” 

7. In section 6.7.1.1 (C-FIND Attributes), we removed paragraphs 2 and 3 because they were 
redundant. 

8. Section 6.7.2 (Modality Performed Procedure Step Attribute Requirements) is now located after 
the section on Modality Worklist C-FIND Attribute Requirements. 

9. The section 6.7.3.1 Pixel representation issues, is revised to clarify the differences between the 
minimum acquired and the minimum stored pixel values. 

10. Table 9 in section 6.7.5 (Attribute Mapping from Modality Worklist Attributes to the Image 
Header) is changed to for closer correspondence with the IHE C-1 Table. 

Please send your corrections, suggestions and comments regarding this version to: 

Herman Oosterwijk 
Otech Inc. 

2001 East Oakshores Drive 
Cross Roads, TX 76227 
herman@otechimg.com 
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Preface to Version 1.1 


Nine months after the release of the Version 1.0 Requirements Document, the HIMSS and RSNA 
published the Integrating the Healthcare Enterprise(IHE) Technical Framework Version 3.0 
document. The IHE document establishes a similar set of DICOM interoperability goals for image 
acquisition equipment, which hopefully will evolve into the definitive requirement specification used 
by all vendors. 

This Version 1.1 of the VA/DOD Modality DICOM Conformance Requirements document follows the 
IHE document as much as possible. There are three areas where the changes in the VA/DOD 
requirements in the Version 1.0 document are needed in order to become compatible with the 
DICOM portion of the IHE Version 3.0 document: 

1) Minor change in the CPT/Local Procedure Code mapping in the response to a Modality Worklist 
query. 

2) Additional support for Modality Worklist query by Requested Procedure ID. The VA/DOD 
Version 1.0 document only required query by Accession Number 

3) Correction of misinterpretation of the Modality Performed Procedure Step complete message. 
The VA/DOD 1.0 document assumed that the MPPS complete message indicated successful 
storage of all images. It only indicates completion of image acquisition, and has no relationship 
to the storage of images. 

This document will reference the IHE requirements where they are identical to the VA/DOD's and 
the direct reference is warranted. The Appendix points out differences between the VA and the IHE 
requirements. 

This requirements document is also incorporating the results of several phases of comments 
received from the vendor community, and the direct input during the workshop held at Silver Spring, 
Maryland on February 16, 1999. Additionally, this Document concentrates more on the sequence 
of events and their relationship with the DICOM message exchanges. 

It should also be noted that this document is not a Standard. It is part of an implementation model 
and as such it does restrict certain aspects of the DICOM standard in order to conform to others. 
Not all interpretations of the DICOM standard will conform to the implementation model defined in 
this document. 2 

Changes for Version 1.1 

This list of changes is included to easily identify sections and paragraphs changed from the 
previous version. The nature of the change is identified in the accompanying note: 

1. The definition of terms has been extended to include all the acronyms appearing in this 
document (Section 1. Definition of terms:) 


2 The version 1.1 document was distributed to the attendees of the May 3-5, 1999 IHE-Federal 
Modality Vendor Workshop. 
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2. As a result of the feedback from the recent workshop on February 16, 1999 and the progress 
made on the IHE project, it became obvious that Modality Performed Procedure Step (MPPS) is 
not going to provide the definitive indication of End of Study as needed by the VA. The VA is 
still planning to utilize the Modality Perform Procedure Step to manage Modality Worklist 
items. As a result, Section 5.4 (DICOM Modality Performed Procedure Step:) has been 
significantly changed to reflect the new intent of the usage of MPPS. 

3. The intended use of Storage Commitment and its relation to the other SOP Classes is clarified. 
The section describing the SOP behavior is defined in section 5.5 (DICOM Storage 
Commitment:). The section is further enhanced by the expected Storage Commitment SCU 
behavior description. 

4. The implementation model has been updated to reflect the association handling policies. For 
details consult Section 6.3 (Association Acceptance Policies) 

5. Section 6.1.2 (Real life events and message sequence relationship) was added to define the 
timeline of events along which the DICOM message exchanges occur between the modalities 
and VA Application Entities 

6. Added section 6.5 . The section describes the entity relations of the VA data objects. 

7. Added a clarification to the section specifying the display of all the attributes on a user screen 
at the modality. 

8. Added clarification. The section has been expanded to describe the SCP behavior in handling 
identical instances. 

9. Section 6.2 (Implementation Model) has been modified to correspond with the distribution of 
functionality across multiple Application Entities. 

10. Section 5.4 (DICOM Modality Performed Procedure Step:) has been modified to reflect the 
revised usage of MPPS. 

11. Removed one of the example specifics from the on page 24 . It created unnecessary confusion. 
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Preface to Version 1.0 


This Requirements Document is based on a RFC, which was issued in November of 1997. The RFC 
process was very successful, and detailed comments were received from many manufacturers as 
well as users. The majority of those comments were included in this version of the document. 
Significant changes in this document with regard to the RFC are: 

• The DICOM Modality Performed Procedure Step Service is incorporated as a requirement. 

• Several optional attributes, which were incorporated in the Image header, have been 
removed eliminating the need for a Standard Extended SOP Class. 

• The requirement to send images from a modality simultaneously to different destinations 
was removed. The requirement to be able to send to different destinations has not changed. 

• Supporting the DICOM Verification SOP class as a Provider has been removed. Supporting 
the DICOM Verification SOP class as a User has been retained. 

• The Type specification of the image attributes is now identical to the Type specification in 
the DICOM standard. For example, this means that the Patient name and Patient ID remain 
Type 2. However, there is now a "VA Type requirement", i.e. certain attributes are always 
required, even although they might be Type 2 according to the DICOM standard. 

• The requirement to incorporate new changes to the DICOM standard has been changed 
from 6 to 12 months. 

• A minimum requirement for the number of characters in a Patient Name, Accession 
Number and Patient ID has been added. 


Several other details have been changed; the reader is encouraged to review the document in its 
entirety. 
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General Preface to this Requirements Document 


The purpose of this Requirements Document is to specify how the modalities should provide the 
DICOM functionality required by the VA. The requirements in this document are mandatory for all 
VA purchases of image producing modality and related equipment. This document is based on a 
Request For Comment (RFC) document, issued in November 1997. Comments received as part of 
the RFC process, when reasonable and applicable, were incorporated into this Requirements 
Document. 

The Veterans’ Health Administration (VHA), Patient Care Services, which represents all of the 
clinical patient care programs that utilize image producing equipment and modalities at the 
Headquarters level, strongly supports and recommends the requirements of this document. This 
document is considered essential to provide interoperability between imaging equipment and 
modalities and the VistA hospital information system, which is necessary for efficacious veteran 
patient care. 

The DOD and IHS also will use this document as the standard requirement for image producing 
modalities and related equipment. 


This document is available online at http://www.va.aov/oa&mm/busopp/formats.htm . The files are 
modality.zip and modality.doc. It is also available on the web site http://www.otechimg.com. 
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1. DEFINITION OF TERMS: 


ASCII 

American Standard Code for Information Interchange 

AE 

Application Entity 

ANSI 

American National Standards Institute 

CR 

Computed Radiography 

CT 

Computed Tomography 

DICOM 

Digital Imaging and Communications in Medicine 

DIMSE 

DICOM Message Service Element 

DIMSE-C 

DICOM Message Service Element Composite 

DIMSE-N 

DICOM Message Service Element Normalized 

DOD 

Department Of Defense 

DX 

Digital Radiography 

FTP 

File Transfer Protocol (part of the TCP/IP protocol suite) 

HL7 

Health Level 7 

HIS/RIS 

Hospital Information System/ Radiology Information System 

ID 

Identifier 

IE 

Information Entity 

IHE 

Integrating the Healthcare Enterprise 

IHS 

Indian Health Services 

HIMSS 

Healthcare Information and Management Systems Society 

IS 

Information System 

IOD 

Information Object Definition 

ISO 

International Standards Organization 

MPPS 

Modality Performed Procedure Step 

NEMA 

National Electrical Manufacturers Association 

MR 

Magnetic Resonance 

OSI 

Open Systems Interconnection 

PACS 

Picture Archiving and Communication System 

PDU 

Protocol Data Unit 

PN 

Person Name 

RFC 

Request For Comments 

RIS 

Radiology Information System 

RSNA 

Radiological Society of North America 

SCP 

Service Class Provider 

SCU 

Service Class User 

SOP 

Service-Object Pair 

TCP/IP 

Transmission Control Protocol/Internet Protocol 

UID 

Unique Identifier 

V A 

Department of Veterans Affairs 

VistA 

VA Hospital Information System Technology Architecture 

VL 

Visible Light 

VR 

Value Representation 

XA 

X-Ray Angiography 
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2.AUDIENCE 

The intended audience of this document is: 

• Technical staff from vendors planning to interface to VistA Imaging. The document is 
intended to clarify the differences to implementers who are well versed in IHE. 

• VA personnel. The document familiarizes the reader with the IHE concepts and puts them 
in context of the VistA Imaging environment 

• Anyone wishes to interface to VistA Imaging 


3. INTRODUCTION: 

3.1. Background and Scope: 

The Department of Veterans Affairs (VA) has been one of the pioneers of implementing Picture 
Archiving and Communications Systems (PACS) in a clinical environment. The VA was also one of 
the first to implement interfaces between commercial PACS systems, image generating modalities, 
and the Hospital/Radiology Information System (VistA), based on the Digital Imaging and 
Communications in Medicine (DICOM) 1 standard. Several VA hospitals are using this technology on 
a daily basis, thereby increasing their efficiency, lowering cost, and reducing turnaround time for 
diagnostic exams. This has a positive impact on improving patient care in the VA hospital 
environment. 

Based on these early implementations, it has become clear that there is a need to specify uniform 
and consistent requirements for modality vendors supporting the DICOM standard. Currently in 
many cases, information that is critical in uniquely identifying a patient or a study (for example the 
accession number) is often entirely missing from the image header, or is encoded in different fields 
(for example as Comments). In addition, the VA found that certain modalities do not accommodate 
a sufficient number of characters in the patient data entry, causing the Patient Name and/or Patient 
ID to be truncated. 

In order to resolve this situation, the VA requires that modality vendors support a common core 
subset of the DICOM standard that would properly communicate this critical patient and study 
information. 

The scope of this document is to define exactly this DICOM core subset in the form of requirements 
for the image producing modalities. These include Magnetic Resonance, Computerized 
Tomography, Ultrasound, Nuclear Medicine, Computed Radiography and other digital radiography 
applications, film digitizers, and digital Xray systems such as Cardiology, Fluoroscopy, and the 
non-radiology Visible Light modalities, such as Cardiology, Dental, Endoscopy, Ophthalmology, 
Pathology, etc. By adhering to this DICOM core subset, compatibility and interoperability with VistA 
imaging will be greatly enhanced. This core subset consists of a required set of attributes for all 
objects that are exchanged, and a set of DICOM services. (DICOM Modality Worklist Management, 
Storage, Modality Performed Procedure Step, Storage Commitment and Verification.) 

The core subset and additional services require no private extensions to the DICOM standard. 
Additional services, beyond the initial core set of capabilities, are included in Annex 8. One or more 


1 National Electrical Manufacturers Association: Digital Imaging and Communications in Medicine 
standard PS 3.1 to 3.14-1998 
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of these additional services, such as Query/Retrieve or extended roles (Provider vs. User), or Print 
might be required depending on the specific application. 
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3.2. HIMMS/RSNA IHE Initiative 

The Healthcare Information and Management Systems Society (HIMSS) and the Radiological 
Society of North America (RSNA) organizations are sponsoring the Integrating the Healthcare 
Enterprise (IHE) initiative to address some of the very same interoperability issues that the VA and 
DOD are trying to sdve. This effort has drawn participation from many leading commercial 
information and imaging systems vendors. Through a series of biannual demonstrations at the 
HIMSS and RSNA annual meetings, IHE provides a framework to improve the interoperability of 
commercial systems in an open, standards-based environment. The real goal of this effort is not 
merely to demonstrate interoperability at the respective shows, but to get the industry to actually 
modify their products so that they will be able to work better together in real life. The IHE hopes to 
achieve this goal by establishing a good standards-based technical framework with which all the 
vendors can comply. 

The IHE initiative has been undertaken with the purpose of creating a highly visible forum and 
showcase for demonstration of interoperability capabilities. While development of standards is a 
very intense area of activity, the IHE connectivity demonstrations seek to provide a framework for 
showcasing accepted standards, and encouraging support of them by health care institutions and 
industry. IHE is primarily an educational effort. An inclusive planning process has resulted in the 
selection of an initial set of transactions for which connectivity will be demonstrated, and will 
determine priorities for subsequent demonstrations on a year-to-year basis. 

The IHE’s vision statement declares pointedly that it is not a standards-making body, but a vendor- 
driven group whose work is intended to bolster ongoing standards efforts. The IHE goal is to 
facilitate interoperability through the judicious use of the existing standards. The IHE Technical 
Framework defines a set of choices in implementation of the DICOM and HL7 standards. Where 
the IHE committees identify gaps in or necessary extensions to current standards, they will submit 
their findings to the appropriate standards body for consideration. 

This VA Requirements Document references the applicable DICOM portion of IHE’s Technical 
Framework Document. 1 The support of the largest government-owned healthcare networks adds 
further momentum to the IHE project and signals the willingness of purchasers, vendors, and 
government software developers to work together toward interoperability. 


1 Sections 4.8 to 4.13 of the IHE Technical Framework V3.0 document dated April 26, 1999. 
HIMSS/RSNA Integrating the Healthcare Enterprise Technical Framework, Version 3.0, available on 
the www.RSNA.orgMHE web site 
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4. DOMAIN OF THIS SPECIFICATION 
4.1. VA Radiology Device Interface Architectures 

The VA currently supports two different architectures with regard to radiology device interfaces, 
depending on whether a commercial PACS system or the VA VistA PACS solution is used. The 
modalities shall perform the same functions whether they directly interface to VistA Imaging or they 
interface through a commercial PACS. This document defines the domain of specification strictly 
as the point of interface between the modality and VistA Imaging. The document cbes not define 
the interface between VistA Imaging and a commercial PACS. 

Architecture 1: Using a commercial PACS system: 




Commercial 
PACS system 


Images and Image 
Management 
■duling Information 
Patient 
igraphic 
ifnation 



Modality 


Figure 1 


This architecture has three high level 
components, the Modality itself, the VistA 
Information System, and a commercial PACS 
system. In this architecture, the Modality will 
interface to the VistA Information system for 
the patient demographic information and to a 
Commercial PACS system for exchanging 
Images and Image Management Information 
(see Fig 1). 


Architecture 2: Using the VistA Imaging System as a PACS system: 



Figure 2 


In this architecture, the PACS system is 
incorporated within the VistA Information 
system (see Fig 2). Note that from a modality 
functional perspective there is no real difference 
between architecture 1 and 2. The interface 
from the modality to a commercial PACS 
system is now used between the modality and 
the VistA Imaging System. 

The domain of this specification i.e. the DICOM 
interface of the modality, is identified in the 
Figures by the shaded area. 
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4.2. Domain relationship with IHE 

This document specifies only a small portion of the IHE defined domain. Figure 3.2-1 of the IHE 
framework 3.0 document is included to illustrate the overlap between the IHE specification and this 
document. This document is only concerned about the interfaces specified in interacting with the 
system from a purely modality centric view. All the items not directly used or directly affected by 
the modality interfaces have been represented in gray color. Whether the modality interfaces to 
VistA Imaging directly or to a Commercial PACS, the interface requirements for the modality do not 
change. 



IHE Figure 3.2-1. System Transactions Overview 


This Document is based on the IHE Technical Framework. The intent is to document notable 
differences from the requirements set forth by the IHE Technical Framework. The document is not 
intended to replace the IHE document but to augment it and provide implementation context. 
Procedural and definition details covered by IHE are not repeated by this document. The reader is 
expected to be fully familiar with the concepts of the IHE Technical Framework. The document 
inherits the relationships, definitions and nomenclature established by the IHE Technical 
Framework. 
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5. REQUIRED DICOM SERVICES: 

The Department of Veteran Affairs requires the DICOM services specified below to be supported by 
a Modality: 

5.1. DICOM Verification Service: 

The modality shall fully support the DICOM Verification SOP Class both as a SCP and aSCU. 
When supporting DICOM Verification as aSCU the modality shall establish an Association with 
another DICOM device and issue a C_ECHO Request. When the modality supports Verification as 
a SCP, it shall accept an association and respond to a C-ECHO request. The VA requires this 
capability of a modality so that it can be used for troubleshooting. Additionally, support of the 
Verification SCP on modalities with no apparent SCPs is dictated by the reverse role negotiation 
requirement of the Storage Commitment Push Model (see DICOM PS 3.2 - B.2.1.3.3.1 [SOP 
Specific Conformance to Verification SOP Class]). 

5.2. DICOM Storage Service: 

The primary function of a Modality is to acquire images. The DICOM Storage service is required in 
order to send those Image objects to specific destinations. The Modalities shall support the 
Storage SOP classes appropriate for the modality, and optionally may support the Secondary 
Capture Storage SOP class. 

5.3. DICOM Modality Worklist: 

The DICOM Modality Worklist service is required, allowing a modality to query for Patient and Study 
information (i.e., issue a “C-FIND” request). For example, the modality can request the list of 
patients that are scheduled based on certain search criteria. The information returned in the O 
FIND responses correspond to the Scheduled Procedure Step level of the information model defined 
by DICOM. 

5.4. DICOM Modality Performed Procedure Step: 

The Modality Performed Procedure Step messages indicate the authoritative start of the procedure 
step (start of image acquisition) and the completion or cancellation of the procedure step (end of 
image acquisition). Although the Modality Performed Procedure Step does not necessarily signal 
the starting and the completion of the transmission of the images, some modality vendors may 
include the delivery of the images to at least the primary destination as part of the Performed 
Procedure Step. The Modality Performed Procedure Step N-CREATE event can be used with the 
Modality Worklist SCP to prevent other modalities from starting the same procedure step. 

The MPPS Complete N-SET message can be used to indicate that the Scheduled Procedure Step 
is eligible for removal from the worklist. 

5.5. DICOM Storage Commitment: 

The VA specifies the use of the Storage Commitment SOP Class Push Model implementation in 
order to guarantee the safe storage of imaging information generated by the modalities. The VA 
system interprets Storage Commitment as a request from a modality to guarantee safe storage of 
the IOD instances. For details see Sections 6.1.2.7 and 6.7.4 
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6.SPECIFIC DICOM REQUIREMENTS: 

6.1. Process steps 

6.1.1. Unique Study and Image Identification: 

The HIS/RIS passes the same Patient and Study information to both the Modality Worklist provider 
and the commercial PACS (if present). The DICOM Study Instance UID attribute, which uniquely 
identifies the study, is assigned by the HIS/RIS and is passed to the Modality Worklist provider and 
the PACS. The Worklist Provider passes this Study Instance UID to the Modality, which 
incorporates it into the Image header. The Modality Worklist provider shall use the Study Instance 
UID that is supplied by the HIS/RIS, and the Modality shall use the Study Instance UID that is 
supplied by the Modality Worklist provider. These requirements allow the images to be properly 
related to the Study within the HIS/RIS and/or PACS. 

In case the Study Instance UID is generated at the modality (i.e. when the RIS is unavailable), the 
modality shall guarantee that this value is unique for the particular object it generates. If a particular 
Image object is sent again later from a particular modality, the same Study Instance UID shall be 
used to identify the Study. 

The Image SOP Instance UID is assigned by the modality and permanently identifies the Image 
object. By definition it must be unique for each Image object. It is not allowed to be subsequently 
changed, for example, when the same image is re-sent from the modality. However, when the 
Image object is modified and clinically significant changes are made, the modality shall create a 
new instantiation. New instances received with the same UID will be ignored. 


6.1.2.Real life events and message sequence relationship 

The model followed by IHE is applicable in describing the real world sequence of events and their 
relationship to message exchanges in the system. The sequence described here does not imply 
any time scale, just the temporal order of events (i.e. event A must occur before event B and so on 
and so forth). 



September 7, 1999 Department of Veterans Affairs 


Page 17 






























Modality Interface DICOM Conformance Requirements 


In each state transition of the process, the underlying information systems exchange the necessary 
messages. Each activity results in the generation of specific HL7 or DICOM messages. Only the 
DICOM interfaces and the modality related messages are described in this document. (Text 
interface messages generated to send to a commercial PACS are not within the scope of the 
document.) 

The individual steps of the process are correlated to the IHE defined steps using the numbering 
scheme established by Figure 3.1-1 of the IHE Technical Framework 


6.1.2.1. Patient Registration (IHE Step 1) 

When the patient is registered, the patient related information is entered into the database. There 
are no modality specific interface actions taken, there are no modality specific messages 
generated. 


6.1.2.2. Order Entry (IHE Step 2) 

The Ordering system generates a new order for the patient. The transaction generates internal 
messages, prepares the patient for the arrival at Radiology. None of the modality specific DICOM 
interfaces are affected. 


6.1.2.3. Patient Registration (Radiology) (IHE Step 7) 

At the time of the arrival of the patient in Radiology, the respective Scheduled Procedure Steps are 
generated from the requested procedures and the information is made available on the Modality 
Worklist. 


6.1.2.4. Worklist (IHE Step 8a) 

The Scheduled Procedure Steps are placed on the Modality Worklist. The worklist is accessible by 
using the MWL service class. 


6.1.2.5. Modality Performed Procedure Step Started. (IHE Step 9) 

The start of the Modality Performed Procedure Step signifies the beginning of image acquisition. 


6.1.2.6. Modality Performed Procedure Step Completed. (IHE Step 11) 

The completion status of the Performed Procedure Step indicates the modality completed the 
actions related to the Scheduled Procedure Step. 


6.1.2.7. Image Instance Storage and Storage Commitment. (IHE Steps 12a &12b) 

The Storage of the first image shall occur only after the start of the MPPS. 


6.1.2.8. Images Available (IHE Step 13a) 

There is currently no DICOM notification message signaling that all the images in a Performed 
Procedure Step have been transferred from the acquisition modality to the archive. Such a 
message would be the natural trigger signal to place the study on the “unread list” for the 
radiologists. The IHE committee recognizes the same deficiency and is working with the DICOM 
committee to correct this situation. The VA and DOD wholeheartedly support this effort. 
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6.1.2.9. Examination Verification(No IHE equivalent) 

In the VistA HIS/RIS, after the study’s images have been safely stored in the image database, the 
technologist verifies the images on a workstation. As a result of this event, the VistA system 
removes the Scheduled Procedure Step from the Modality Worklist. 

6.2. Implementation Model 

The Implementation Model describes the function of the image producing modality related to the 
DICOM services. The DICOM services for the modality are implemented by a software process, 
called an “Application Entity” (AE). The “bubble diagram” (Application Data Flow Diagram) shows 
the interaction of the modality AE with the outside world across the dashed line, i.e. the DICOM 
interface. The Application Data Flow Diagram depicts graphically the relationship of the modality 
DICOM AE with local functions at the modality as well as the relationship with external activities. 
Note that the modality DICOM AE receives data from the Modality Worklist SCP, sends images to 
the Remote Storage SCP, and communicates the procedure status and related information using 
the Modality Performed Procedure Step. The modality will also function as a User and Provider of 
the Verification Service. The implementation model described below functions as an illustration of a 
potential implementation of the DICOM services. Note that a Modality for example might implement 
more than one Application Entity (AE) for the different services. 
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The Remote Storage SCP corresponds to the IHE Image Archive. In the IHE model the Modality 
Worklist SCP resides on the departmental system/order filler, the Modality Performed Procedure 
Step SCP resides on the Modality Performed Procedure Step Manager, the Storage Commitment 
SCP resides on the Image Manager. 

6.3. Association Acceptance Policies 

The VistA environment typically implements the DICOM services using multiple Application Entities. 
Each of these AE's supports the Verification SOP class (as a SCU/SCP) and one or more 
additional SOP classes. The modality SCUs utilizing the services of the SCPs shall be prepared to 
support each service class residing on a separate AE in the VA environment. 

Each modality SCU shall be able to be configured to use a different AE SCP for each of the SOP 
Classes (Storage, Modality Worklist, Modality Performed Procedure Step, and Storage Commit). 
This provides the greatest flexibility for the modality when interfacing to different system 
configurations, and is consistent with the implicit assumption of the IHE model depicted in Figure 
3.2-1 of the IHE Technical Framework document. 

The modality shall be capable of utilizing the full 16-bit range (1-65535) of port numbers. 

6.4. AE Specifications 
6.4.1.SOP Class Support 

The VA modality interface shall provide Standard Conformance to the following DICOM Version 3.0 
SOP Class(es): 


Table 1: Required SOP Classes: 


SOP CLASS NAME 

SOP CLASS UID 

USAGE 

Modality Storage SOP Class (depends on modality 
Type, e.q. CT, MR, etc.) 

1.2.840.10008.5.x.x.x.x 

SCU 

Modality Worklist Information Model Find 

1.2.840.10008.5.1.4.31 

SCU 

Modality Performed Procedure Step SOP class 

1.2.840.10008.3.1.2.3.3 

SCU 

Verification SOP Class 

1.2.840.10008.1.1 

SCU/SCP 

Storage Commitment Push Model SOP Class 

1.2.840.10008.1.20.1 

SCU 


Note 1: Support of the retired Nuclear Medicine and Ultrasound Image Storage SOP classes is 
optional, support of the new SOP classes is required. 

Note 2: A modality can optionally support the Secondary Capture SOP class in addition to its “true” 
SOP class such as DX, XA, VL, CT, MR, PT etc. Support of Secondary Capture ONLY is not 
sufficient (except for Film Digitizer modalities). 

Note 3: Computed Radiography modalities are required to support the DX SOP Gasses in addition 
to the CR SOP Class. 

Note 4: Some modality vendors seem to implement a Verification service using a non-DICOM 
mechanism such as FTP. There is no guarantee that this will work and it is unacceptable if it is 
implemented in lieu of the true DICOM Verification service. 
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6.4.2. Presentation Context 

Each SOP class supports a particular Presentation Context, which is the combination of the SOP 
class as specified above in Section 6.4.1 and the Transfer Syntax. The Transfer Syntax defines the 
encoding of the DICOM basic elements, i.e. its attributes and how the data is represented. The 
encoding of the attributes, in the form of a so-called Value Representation, can be done in two 
ways, i.e. either Explicitly or Implicitly. This means either that each attribute has an explicit 
specification as part of the Data Element Field that represents its Value Representation, or that it 
does not and it is assumed that the receiver implicitly knows the Value Representation from 
interpreting the Attribute Tag. For example, when receiving the Attribute “Patient Name” in an 
Explicit Transfer Syntax, there is an additional “Person Name” field (i.e., “PN”) to identify the Value 
Representation. In the case of an Implicit Value Representation, the Value Representation is 
assumed to be known by the receiver and is not explicitly specified. 

The Transfer Syntax of the modality shall match the specification in Table 2 and 3: 

Table 2: Proposed Presentation Context for Verification, Modality Worklist, 
Storage Commitment, and Modality Performed Procedure Step: 


Presentation Context Table 

Ab 

Name 

stract Syntax 

UID 

Transfer S' 
Name List 

^ntax 

UID List 

Role 

Ext. 

Neg. 

Verification 

1.2.840.10008.1.1 

Implicit VR Little Endian 

1.2.840.10008.1.2 

scu 

None 

Worklist 

1.2.840.10008.5.1.4.31 

Implicit VR Little Endian 

1.2.840.10008.1.2 

scu 

None 

MPPS 

1.2.840.10008.3.1.2.3.3 

Implicit VR Little Endian 

1.2.840.10008.1.2 

scu 

None 

Storage 

Commitment 

1.2.840.10008.1.20.1 

Implicit VR Little Endian 

1.2.840.10008.1.2 

scu 

None 


Table 3: Proposed Presentation Context for all Storage SOP classes: 


Presentation Context Table 

Abstract Syntax 

Transfer Syntax 

Role 

Extended 

Name 

UID 

Name List 

UID List 


Negotiation 

See Note 1 

See Note 1 

Implicit VR Little Endian 

1.2.840.10008.1.2 

SCU 

None 

See Note 1 

See Note 1 

Explicit VR Little Endian 

1.2.840.10008.1.2.1 

scu 

None 


Note 1: Applicable for all Storage SOP classes 

The preferred transfer syntax that will be accepted by the SCP will be the Explicit VR Little Endian. 
(The Explicit VR transfer syntax is preferred over the default, implicit VR, because it gives more 
complete information about the attribute.) 

A modality, at its option, could propose additional Transfer syntaxes, such as Big Endian or 
compressed. Those will be ignored by the PACS/VistA system. 

6.5. Hierarchical Integrated Data Model 
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The VA uses two forms of a single accession number to track radiology examinations. The first and 
more complete Long Case Number has the representation MMDDYY-NNNNN, where NNNNN may 
be 1-5 digits long. The VA also uses a user-friendly shortcut for the accession number, called the 
Short Case Number, which consists of just the trailing numeric portion of the Long Case Number 
(that is, NNNNN). Since the relationship between the Imaging Service Request and the Requested 
Procedure is 1:1, the VA has elected to use the Long Case Number to identify the Imaging Service 
Request, and the Short Case Number to identify the Requested Procedure, that is, to be the 
Requested Procedure ID. This corresponds to the ER model established and described in the IHE 
Technical Framework document (section 3.3 Data Model). Other references to Accession Number 
in this document refer to the Long Case Number. 

The Scheduled Procedure Step ID is meaningful for requested procedures resulting in multiple 
performed steps on the same or different modalities. An example would be a composite 
fluoroscopic study where the same X-Ray generator is used to take a set of supporting CR 
images.The IHE Data Consistency model (IHE Figure C-1) applies with two modifications. The 
mapping from Imaging Service Request to Requested Procedure is 1:1, not 1 :n, and the mapping 
from the Scheduled Procedure Step to the Performed Procedure Step is 1:1, not 0-n:0-m. 
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Image or Stand-alone 
SOP Instance 


Imaging Service 
Request/ 
Filler Order 


Requested 

Procedure |Ref. St. Seq. 121 
|{Req. Pr. ID)~| 

I {Study Instance UIdTI 



I-Patient 


Scheduled 
Pr ocedure Step 

|{Sch. Pr. ID) I 


I St. Inst. UID Till 

Performed 
Proc. Step 


Ref. St. Seq. [31 


I-Study 

1 St. Inst. UID~Ti~i! 


Ref. St. Comp. Seq. [3] 
{Series-last: ITinfl]} 

I-Series 

Req. Pr. ID (2/3) 
Sch. Pr. St. ID [2/3] 


Image. Inst. UID [1] 


I-Image 

I (SOP Instance UID [1]} I 


*** This relationship may not exist “0-1 to n” but “0-n to 
m” when multiple Scheduled Procedure Steps are satisfied 
by one Performed Procedure Step. 


: An Attribute which is a unique identifier (DICOM UID) or an identifier (DICOM ID) or for the entity 
: An Attribute which is used in the entity to reference another entity as show by the associated arrow. 

: The Attribute Type as defined by DICOM for this entity (IHE may strengthen this requirement) 

: A relationship between two entities using a unique identifier (DICOM UID) 

: A bidirectional relationship between two entities using a pair of unique identifiers (DICOM UID) 

: A relationship between two entities using a simple identifier (DICOM ID) 

: Cardinality of the relationship between the entitties, not the identifiers. (Direction of the arrow is irrelevant to cardinality.) 


IHE Figure C-1. Data Consistency Model: Modality Worklist Information Model, Image and 
Standalone lODs and Modality Performed Procedure Step IOD 
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6.6. Functional Requirements 

The Modality shall support all of the following modes of operation: 

1. Send images to multiple destinations. The different destinations should be operator 
selectable. 

2. As an option, for some specific modalities (e.g. Angiography, Cardiology), it may be 
necessary that the operator be able to select a subset of clinically significant images to be 
sent to a specific destination. 

3. Send images automatically without any operator interaction to its destinations during the 
acquisition (send as you go). 

4. Send images to its destination initiated by an operator at the modality (manual mode) 

5. Send images automatically after a configurable period of time if the images were not sent 
manually prior to the expiration of the interval timer (manual mode, automatic time out). 

6. The modality shall retry failed transmission either automatically or initiated by the operator. 

7. The modality shall retry failed storage commitments 


6.7. Specific attribute Requirements 
6.7.1.Modality Worklist C-FIND Attribute Requirements (IHE Step 8) 

There are different scenarios under which image producing equipment can use the Modality Worklist 
service to obtain patient and study information from a Modality Worklist provider. In each instance, 
the modality “pulls” the data (i.e uses a DIMSE-C C-FIND) to obtain the data from the Modality 
Worklist provider. Different capabilities are needed to handle the different situations that occur in 
the hospital information system environment: 

Example 1 - Current Radiology Study 

A technologist wants to obtain patient and study information on a currently active radiology study. 
The radiology information system software is sufficiently developed to output event transactions that 
signal the patient's arrival in the radiology department, as well as the completion of the examination. 
These events are used to dynamically populate and prune a small database, which is used to 
support the classic Modality Worklist provider. 

The technologist can obtain the patient and study information for a single case either by entering 
the Accession Number or the Requested Procedure ID, or can obtain the entire set of active 
patients and studies for the modality, and then pick the case from the list. 


Example 2 - Prior Radiology Study 

It is sometimes necessary to scan film of a previous radiology study. In this situation, the Radiology 
Information system does not generate any event transactions that can be used to update the 
classic Modality Worklist provider database. Nonetheless, given the Accession Number of the 
previous study, the VistA Modality Worklist provider can obtain the information about the study 
directly from the radiology information system database. 
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Example 3 - Non-Radiology Study 

The VistA Imaging System supports non-radiology image producing DICOM modalities. Outside of 
Radiology, the Hospital Information System may not generate any event transactions about non- 
radiological imaging examinations, and the classic Modality Worklist provider database can not be 
constructed. Again, given the Accession Number, the VistA Modality Worklist provider can obtain 
appropriate information about the study from the specific application database within the hospital 
information system. 


These three examples demonstrate the requirement for supporting the Accession Number and 
Requested Procedure ID query capability of Modality Worklist. 

The timing of the Modality Worklist query is very important. The radiology staff takes responsibility 
for the study and registers the patient in the department. This produces the “arrival event”. 

Because of the way the VA’s radiology information system works, the “arrival event” is the first 
notification that a Modality Worklist provider receives about a study. The most efficient use of 
Modality Worklist facility would be to perform a single query shortly after the patient has been 
registered. A query prior to the arrival event produces negative results. 

Frequently querying the Modality Worklist provider (i.e., “polling”) to retrieve patient data has proven 
to be inefficient. It is therefore strongly discouraged as the primary method for obtaining such data. 

A major issue surfaced in early implementations of Modality Worklist within the VA system. In 
some implementations, the user interface design of the modality makes it relatively easy to select 
the wrong patient information to associate with a particular image. The result is a mismatch of the 
patient demographic data and image(s), with serious effects on data integrity and potentially 
adverse effects on patient safety. Therefore, in the Accession Number, Requested Procedure ID, or 
Worklist query, it is mandatory that the user interface require a second patient/study 
identification verification step to ensure that the images are matched to the correct patient 

6.7.1.1. C-FIND Attributes 

The Basic Modality Worklist SCP shall support the Accession Number (0008,0050) and Requested 
Procedure ID (0040,1001) as a required Matching Key attributes of the C-FIND Request. 

The Accession Number or Requested Procedure ID shall be retrieved with Single Value Matching 
(that is, wildcard matching shall not be allowed; an error shall be returned). 

Because the relationship between the Imaging Service Request and the Requested Procedure is 
1:1, the Accession Number or Requested Procedure ID queries produce identical results. The two 
queries and their arguments can be used interchangeably. The SCP will always return the 
Accession Number in the Accession Number Return Key attribute and Case Number in the 
Requested Procedure ID Return Key attribute. Note that this is even true if a Case Number is used 
in the Accession Number field of a query. 

Table 4 specifies the Matching and Return Key attributes showing the mapping from the VistA data 
elements. The table below represents the list of attributes that VA requires to have retrieved by the 
modality and inserted into the corresponding entry fields cf the user interface. Most of the 
information specified in Table 4 was selected based on input from the clinicians using the systems 
on a daily basis. 
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ATTRIBUTES FOR 


VistA Name 


Table 4 

THE MODALITY WORKLIST INFORMATION 


Description/ Module 


Scheduled Procedure Ste 


Scheduled Procedure Step Sequence 


>Scheduled Station AE Title 


>Scheduled Procedure Step Start Date 


>Scheduled Procedure Step Start Time 


> Scheduled Procedure Step Location 


>Modality_ 


>Scheduled Performing Physician's Name 


>Scheduled Procedure Step description 


>Scheduled Action Item Code Sequence 


»Code Value 


»Coding Scheme Designator_ 


»Code Meanin 


>Scheduled Procedure Step ID 


Requested Procedure 


Requested Procedure Comments 


Requested Procedure Description 


Requested Procedure Code Sequence 


>Code Value 


MODEL 



0040,0100 


(0040,0001) 


0040,0002 


Room location for study 


Modality_ 


Technologist / Physician 
performing the study_ 


VA Procedure Description 


VA Procedure (see note 1) 


VA Procedure Code (IEN 


VA Coding Scheme (L) 


VA Procedure Description 


0040,0011 


(0008,0060) 


(0040,0006) 


ninsiimiiim 


(0040,0008) 


milllBIlillllll 


(0008,0102) 


0008,0104 


(0040,0009) 


To be used as needed 


CPT Procedure Description 


CPT Procedure 


CPT Procedure Code 


CPT Codinq Scheme (C4 


CPT Procedure Description 


Study SOP Instance UID 


Case Number (NNNNN) 


Attendinq Physician 


) 

>Coding Scheme Designator 

( 

0008,0102 


>Code Meaning 


Study Instance UID 


Requested Procedure ID_ 


Names of Intended recipients of results 


Imaging Service Request 


Imaging Service Request Comments 


Accession Number (MMDDYY-NNNNN 


Requesting Physician 


Reauestina Service 


Referring Physician's Name_ 


0040,1400 


(0032,1060) 


lOfflCWHllSElB 


(0008,0100) 


0008,0102 


(0008,0104) 


ftlllMlHHHIMl 


(0040,1001) 


0040,1010 


To be used as needed 


Accession Number 


Ordering Physician 


Request™ Service 


Primary Care Provider 


Visit Information 


Patient Location 


(0040,2400) 


0008,0050 


(0032,1032) 


KlfflCWHlMCll 


(0008,0090) 


Current Patient Location 


Patient Identification 


Patient's Name 


Patient ID 


Other Patient ID’s 


Patient Demographic 


Patients Birth Date 


Patient's Sex 


Ethnic Grou 


Patient Comment 


Patient Name 


Patient ID 


Other Patient or Study ID's 


0010,0010 


( 0010 , 0020 ) 


IMUIIMWIOl 


Patient Date of Birth 


Patient Sex 


Patient Race 


Patient Comment 


IMiBBI 


(0010,0040) 


0010,2160 


(0010,4000) 


Preqnancy Status 

Preqnancy Status 

Allergies 

Medical Alerts 


0010,21 CO 


( 0010 , 2000 ) 
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VistA Name 

Description/ Module 

Taq 

Reason for Study (history) 

Additional Patient History 
(see note 2) 

(0010,21 B0) 


Note 1: Starting in Version 1.1, the Scheduled Action Item Code Sequence contained the VA (local) 
procedure codes, in order to be compatible with the IHE. 

Note 2: In the VA HIS/RIS the reason for the study is often a short patient history summarizing the 
condition of the patient and giving background information for the reason for the study. It usually 
exceeds the 64 character Long String Value Representation provided by the DICOM standard 
attributes Reason for the Study (0032,1030), Reason for the Request Procedure (0040,1002), and 
Reason of the Imaging Service Request (0040,2001). In order to faithfully communicate this 
essential field, the VA has chosen to map it to the Additional Patient History (0010,21 B0) attribute. 

6.7.2.Modality Performed Procedure Step Attribute Requirements 

Modality Performed Procedure Steps correspond to IHE step 9. The Modality Performed Procedure 
Steps track the acquisition of the image instances. 


Table 5 

Modality Performed Procedure Step SOP CLASS N-CREATE, N-SET AND 

FINAL STATE ATTRIBUTES 


Attribute Name 

Tag 

Req. Type 
N-CREATE 

Req.Type 
N-SET 

Performed Procedure Step Relationship 

Scheduled Step Attribute Sequence 

(0040,0270) 

1 

Not allowed 

>Study Instance UID 

(0020,000D) 

1 

Not allowed 

>Accession Number 

RHH 

2 

Not allowed 

>Requested Procedure ID 

(0040,1001) 

2 

Not allowed 

>Requested Procedure Description 

(0032,1060) 

2 

Not allowed 

>Scheduled Procedure Step ID 



2 

Not allowed 

>Scheduled Procedure Step Description 



2 

Not allowed 

Patient's Name 

(0010,0010) 

r 2 

Not allowed 

Patient ID 

(0010,0020) 

2 

Not allowed 

Patient's Birth Date 

mmmm 

2 

Not allowed 

Patient's Sex 

(0010,0040) 

2 

Not allowed 

Performed Procedure Step Information 

Performed Procedure Step ID 

(0040,0253) 

1 

Not allowed 

Performed Station AE Title 

(0040,0241) 

1 

Not allowed 

Performed Station Name 

HSTS£RVSE2!3H 

2 

Not allowed 

Performed Location 

(0040,0243) 

2 

Not allowed 

Performed Procedure Step Start Date 

(0040,0244) 

1 

Not allowed 

Performed Procedure Step Start Time 

W1 

1 

Not allowed 

Performed Procedure Step Status 

mmm&m 

1 

3 

Performed Procedure Step Description 

(0040,0254) 

2 

3 

Performed Procedure Type Description 

(0040,0255) 

2 

3 
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Attribute Name 

Tag 

Req. Type 
N-CREATE 

Req.Type 
N-SET 

Procedure Code Sequence 

(0008,1032) 

2 

3 

>Code Value 

(0008,0100) 

1C 1 

1C 

>Codinq Scheme Desiqnator 

wsmsEm 

1C 

1C 

>Code Meaninq 

(0008,0104) 

3 

3 

Performed Procedure Step End Date 

(0040,0250) 

2 

3 

Performed Procedure Step End Time 

(0040,0251) 

2 

3 

Image Acquisition Results 

Modality 

wmmrn 

1 

Not allowed 

Study ID 

(0020,0010) 

2 

Not allowed 

Performed Series Sequence 

(0040,0340) 

2 

3 

Performing Physician's Name 

(0008,1050) 

2C 

2C 

Protocol Name 

mm 

1C 

1C 

>Operator's Name 

(0008,1070) 

2C 

2C 

>Series Instance UID 

wmmsi 

1C 

1C 

>Series Description 

(0008,103E) 

2C 

2C 

Petrieve AE Title 

m 

2C 

2C 

Peferenced Image Sequence 

(0008,1140) 

2C 

2C 

»Referenced SOP Class UID 

(0008,1150) 

1C 

1C 

»Referenced SOP Instance UID 

(0008,1155) 

1C 

1C 

All other attributes from Radiation Dose Module 


3 

3 

and Billina and Material Code Module 





6.7.3. G-STORE Attribute Requirements: 

The attributes that shall be sent as part of the composite objects shall adhere to the DICOM 
specification with regard to their Type and syntax. Although certain attributes might not have to be 
provided according to their Type definition in the DICOM standard, the VA requires those attributes 
specified in Table 5 as “Required” to be always sent with a length greater than 0 bytes. 

The Modality shall be equipped with overrides to allow the technologist to manually enter patient 
and study data into the system in the event that such data is not available automatically from the 
Modality Worklist SCP. In no circumstances shall the modality have “built-in” default values for this 
data. The VA is aware that in the case that the Modality Worklist is unavailable, the information 
might not necessarily be unique or correct. The technologist will do a "best effort" to enter this data 
correctly. 

“No MWL” in the table signifies that the attribute is required even when no Modality Worklist service 
is available (it could be temporary unavailable) 

“With MWL” in the table means that the attribute values from the Modality Worklist (and no other 
values) must be used 

“MWL + MPPS” means the relevant attributes from the Modality Worklist are required to be used, 
when Modality Performed Procedure Step is supported 


1 Types 1C and 2C are required if the sequence item is present. 
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Table 6 

IMAGE STORAGE ATTRIBUTES 


Attribute Tag 

Description 

No MWL 

With MWL 

MWL+MPPS 


Patient Name 



ETTlWrUBi 

(0010,0030) 

Patient's Birth Date 


Required 

Required 

(0010,0020) 

Patient ID 

is&KiU 

llSElSiliiil 

■saaiBHRUrai' 

(0010,0040) 

Patient's Sex 

Required 

Required 

Required 

fm; 

Ethnic Group 




(0010,1000) 

Other Patient ID’s 




(0010,21 B0) 

Additional Patient History 




(0010,4000) 

Patient Comments 




(0008,0090) 

Referrina Physician's Name 

Required 

Required 

Required 

(0008,1048) 

Physician(s) of Record 





Study ID 




—AH 

Study Instance UID 


wmmmi 

wmrnmm 

(0008,0020) 

Study Date 




(0008,0050) 

Accession Number 




(0008,1030) 

Study Description 





Modality 


wmmm 

nmmmm 

(0008,0070) 

Manufacturer 

Required 

Required 

Required 

ibhb; 

Institution Name 

IIEJSIffiilS 



(0008,1010) 

Station Name 

Required 

Required 

Required 


Manufacturer Model Name 

IIEKIBPhSI 


air- ^>53' 

(0008,1070) 

Operators’ Name 




(0008,1111) 

Referenced Study Component 
Sequence 



Required 

wiMhxmme* 

Software Version 




(0018,1030) 

Protocol Name 



Required 

(0040,0253) 

Performed Procedure Steo ID 



Required 

(0040,0244) 

Performed Procedure Step Start 
date 



Required 

(0040,0245) 

Performed Procedure Step Start 
time 



Required 

(0040,0254) 

Performed Procedure Step 
Description 



Required 

(0040,0275) 

Requested Attributes Sequence 



Required 


Requested Procedure ID 




(0040.0009) 

Scheduled Procedure Step ID 



Required 

(0040,0007) 

Scheduled Procedure Step 
Description 



Required 


The modality shall support at least the number of characters specified for the following Attributes: 


Patient Name: 

32 

Patient ID: 

16 

Accession number: 

16 
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6.7.3.I. Pixel representation issues. 


Attribute Taq 

Description 

Required/allowed values 

(0028,0004) 

Photometric Interpretation 

MONOCHROME1, MONOCHROME2 or RGB 
(see Note 1) 


Note 1: DICOM images contain the attribute Photometric Interpretation (0028,0004), which for 
monochromatic images specifies whether the minimum pixel value is intended to be displayed or 
printed as black or white. 

The concept of how a pixel value is intended to be displayed is different from the concept of how a 
pixel value is related to incident X-ray intensity (or inversely, how a pixel value is related to X-ray 
attenuation). This is not specified at all in any existing DICOM objects. Thus, regardless of 
whether the minimum pixel value is intended to be displayed as black (MONOCHROME2) or white 
(MONOCHROME1), whether it corresponds to air or bone/lead/contrast is unspecified in DICOM. 

The most common expectation of a radiologist is that air be displayed as black, and 
bone/lead/contrast be displayed as white. An exception is for subtracted images, in which the 
radiologist's preference varies, and it is sometimes desired to show the contrast as black on a white 
background. 

There is also an interaction with the area outside the display shutter, which should usually be 
shown as black. Display workstations should not invert the area outside the shuttered area when 
the image is inverted. 

Accordingly, the VA requires of all Xray modalities that, if images are sent with a Photometric 
Interpretation of MONOCHROME2 either: 

• air will always be sent as the minimum acquired pixel value 1 , 

• the system may be configured such that air will always be sent as the minimum acquired 
pixel value, or 

• the operator can follow a procedure such that air will be sent as the minimum acquired pixel 
value and the area outside the display shutter will be black. 

If images are sent with a Photometric Interpretation of MONOCHROME1 either: 

• air will always be sent as the maximum acquired pixel value, 

• the system may be configured such that air will always be sent as the maximum acquired 
pixel value, or 


1 1n this context acquired pixel value is the resulting value of the digitized X-ray energy at the 
detector. The minimum or maximum acquired pixel value is not necessarily the minimum or 
maximum pixel value in the image. The pixel representation usually allows for pixel values outside 
of the range of the acquired pixel values. (For example: if an image is using 12 bit signed data 
representation and the ADCs convert to 10 bits; air may be represented as -512, but the minimum 
pixel value may be as low -2048.) 
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• the operator can follow a procedure such that air will be sent as the maximum acquired 
pixel value and the area outside the display shutter will be black. 

It is expected that future DICOM objects will follow the model proposed in Supplement 32 (Digital 
Radiography) which specifies an additional attribute, Pixel Intensity Relationship Sign, which 
defines the relationship of pixel value to XRay intensity, and allows workstations, displays and 
printers to exercise the radiologist's preference as to whether or not air is displayed as black or 
white. It is recognized that the semantics of existing DICOM objects cannot be altered by a Change 
Proposal to address this issue, since that would break existing implementations that have been 
made in good faith. 


6.7.4.Storage Commitment N-Event Report and N-Action Attribute Requirements: 

Under most circumstances, it is preferable to commit all images of a study at one time. Usually 
the practice of individually committing SOP instances is discouraged. However, there are some 
situations (e.g., ship-to-shore teleradiology applications) where it may be desirable to commit image 
instances one at a time as they are sent. The modality must be configurable to operate in both 
modes. 

The VA system specifies the Storage Commitment Push model. The VistA system always returns 
the N-EVENT-REPORTs on a separate association. This association is opened with reverse role 
negotiation, that is, the Calling AE is the SCP and the Called AE is the SCU (PS 3.41996 Annex 
J.2.1). 

In the VistA system, Storage Commitment indicates the safe storage and insertion of the instances 
into the image database after linking the image instances with the proper patient and study in the 
VistA database. If image objects that have been received by VistA can not be linked properly to the 
corresponding patient and study, safe storage can not be achieved and the storage commitment will 
fail. 

After an N-ACTION request containing the Study Component Sequence has been received, the 
Storage Commitment N-EVENT-REPORT message is returned upon one of several triggering 
events: 

1) An N-EVENT-REPORT message with status of success will be returned if all the image 
objects have already been received, linked into the database, and safely stored. 

2) If the image objects have not been completely received, or they have not been linked to the 
patient and study at the time of the N-ACTION request message is received, and an N- 
EVENT-REPORT message with status of success will be returned later upon successful 
completion of the these steps. 

3) If a sufficiently long period of time has elapsed and the image objects have not been safely 
stored and inserted into the image database, the N-EVENT-REPORT message with the 
status of failure will be returned. The error conditions for Storage Commitment are returned 
in the Failed SOP sequence. 

The requesting systems shall generate a new transaction UID for each N-ACTION request, 
regardless of the receipt of the corresponding N-EVENT-REPORT. 

The modality shall retry a failed commitment a configurable number of times. 
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Table 7 

STORAGE COMMITMENT REQUEST - ACTION INFORMATION 


Action Type 
Name 

Action 
Type ID 

Attribute 

Tag 

Requirement Type 
SCU/SCP 

Request 

1 

Transaction UID 

(0008,1195) 

1/1 

Storage 


Referenced SOP Sequence 

wsmm ■ 

1/1 

Commitment 


Referenced SOP Class UID 

(0008,1150) 

1/1 



Referenced SOP Instance UID 

■HU 

1/1 



Referenced Study Component 
Sequence 

(0008,1111) 

1C/1 



Referenced SOP Class UID 


1/1 



Referenced SOP Instance UID 

I (0008,1155) 

1/1 


Table 8 

STORAGE COMMITMENT RESULT - EVENT INFORMATION 


Event Type 
Name 

Event 
Type ID 

Attribute 

Tag 

Requirement Type SCU/SCP 

Storage 

1 

Transaction UID 

msmBM 

-/I 

Commitment 


Referenced SOP 

(0008,1199) 

-/I 

Request 


Sequence 



Successful 


Referenced SOP 

Class UID 

(0008,1150) 

-/I 



Referenced SOP 
Instance UID 

(0008,1155) 

-/I 

Storage 

2 

Transaction UID 

(0008,1195) 

-/I 

Commitment 


Referenced SOP 

(0008,1199) 

VIC 

Request 

Complete 

Failures 


Sequence 


This Attribute shall be provided if 
Storage Commitment for one or 
more SOP Instances has been 

Exist 




successful 



Referenced SOP 

Class UID 

(0008,1150) 

-/I 



Referenced SOP 
Instance UID 

(0008,1155) 

-/I 



Failed SOP Sequence 

(0008,1198) 

-/I 



Referenced SOP 

Class UID 

(0008,1150) 

-/I 



Referenced SOP 
Instance UID 

(0008,1155) 

-/I 



Railure Reason 

(0008,1197) 

-/I 
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6.7.5.Attribute Mapping from Modality Worklist Attributes to the Image Header 

Table 9 summarizes the mapping from the attributes from the Basic Modality Worklist SCP to the Modality for inclusion in the Image header as well 
as in the Modality Performed Procedure Step (MPPS). Note that the requirements conform the DICOM standard, i.e. a single Requested Procedure 
may involve one or more pieces of equipment. The Scheduled Procedure Step involves only one piece of Imaging equipment. 

Table 9 1 

Attribute Mapping from Modality Worklist to Image Header and Modality Performed Procedure Step Attributes 


VA Field 

Modality Worklist Attribute 

Image Header Attribute 

MPPS Attributes (N-Create,N-Set) 

Name 

DICOM Name 

Tag 

DICOM Name 

Tag 

DICOM Name 

1 Tag 

Patient Name 

Patient Name 

(0010,0010) 

Patient Name 

(0010,0010) 

Patient Name 

(0010,0010) 

Patient DOB 

Patient's Birth Date 

(0010,0030) 

Patient's Birth Date 

(0010,0030) 

Patient’s Birth Date 

(0010,0030) 

Patient ID 

Patient ID 


Patient ID 

IhliHiIilMH 

Patient ID 

wmmm 

Patient Sex 

Patient's Sex 

(0010,0040) 

Patient Sex 

(0010,0040) 

Patient Sex 

(0010,0040) 

Patient Race 

Ethnic Group 


Ethnic Group 

HI 


Other Patient 

or Study ID's 

Other Patient ID’s 

(0010,1000) 

Other Patient ID’s 

(0010,1000) 


Reason for 

Additional Patient 

(0010,21 B0) 

Additional Patient 

(0010,21 B0) 




History 


History 









Scheduled Attribute 
Sequence 

(0040,0270) 

Study 

Instance UID 

Study Instance UID 

(0020,000D) 

Study Instance UID 

(0020,000D) 

>Study Instance 

UID 

(0020,000D) 

Accession # 

Accession Number 

(0008,0050) 

Accession Number 

(0008,0050) 

>Accession Number 

(0008,0050) 




Requested attribute 
sequence 

(0040,0275) 


Case # 

Requested Procedure 

ID 

(0040,1001) 

>Requested 

Procedure ID 

(0040,1001) 

>Requested 
Procedure ID 

(0040,1001) 


Scheduled Procedure 
Step ID 

(0040,0009) 

>Scheduled 

Procedure Step ID 

(0040,0009) 

>Scheduled 
Procedure Step ID 

(0040,0009) 


Scheduled Procedure 

(0040,0007) 

>Scheduled 

(0040,0007) 

>Scheduled 

(0040,0007) 


1 Note that the table is identical to the IHE Technical Framework Table C-1 with the additions of the VistA field name and DICOM Tag columns. 
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VA Field 
Name 

Modality Worklist Attribute 

Image Header Attribute 

MPPS Attributes (N-Create,N-Set) 

DICOM Name 

Tag 

DICOM Name 

Tag 

DICOM Name Tag 


Step description 


Procedure Step 
description 


Procedure Step 
description 


Scheduled Action 

Item Code Sequence 

(0040,0008) 

>Scheduled Action 

Item Code Sequence 

(0040,0008) 

>Performed Action (0040,0260) 

Item Code 

Sequence 

Patient 

Comments 

Patient Comments 

(0010,4000) 

Patient Comments 

(0010,4000) 


Primary Care 
Provider 

Referring Physician’s 
Name 

(0008,0090) 

Referring Physician’s 
Name 

(0008,0090) 


Attending 

Physician 

Names of Intended 
Recipients of Results 

(0040,1010) 

Physician(s) of 

Record 

(0008,1048) 



Modality 

(0008,0060) 

Modality 

(0008,0060) 

Modality (0008,0060) 

Technologist 

performing 

study 

Scheduled Performing 
Physician’s Name 

(0040,0006) 

Operators’ Name 

(0008,1070) 


Room for 
study 

Scheduled Procedure 
Step Location 

(0040,0011) 

Performed Procedure 
Step ID 

(0040,0253) 

Performed (0040,0253) 

Procedure Step ID 




Performed Procedure 
Step Start date 

(0040,0244) 

Performed (0040,0244) 

Procedure Step 

Start date 




Performed Procedure 
Step Start Time 

(0040.0245) 

Performed (0040.0245) 

Procedure Step 

Start Time 




Performed Procedure 
Step Description 

(0040,0254) 

Performed (0040,0254) 

Procedure Step 

Description 




Referenced Study 
Comp. Sequence 

(0008,1111) 





Referenced SOP 

Class UID 

(0008,1150) 

Affected SOP Class (0000,0002) 

UID 
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VA Field 
Name 


Modality Worklist Attribute 


Imaqe Header Attribute 

DICOM Name 

Tag 

Referenced SOP 
Instance Ul 

(0008,1155) 


MPPS Attributes (N-Create,N-Set 


DICOM Name I Tag 


Affected SOP (0000,1000) 

Instance UID 























Modality Interface DICOM Conformance Requirements 


7. C0MMUNICATI0N PROFILES 

7.1. TCP/IP stack 

The TCI/IP stack shall be the only supported protocol. 

7.2. Datalinkand Physical media: 

Modalities shall support 10 BaseT, and/or 100 BaseT 

7.3. Configurable parameters 

All parameters that are required to be configurable including their range shall be specified by the 
modality. This includes, but is not limited to: 

• Number of simultaneous associations 

• Max PDU sizes 

• Time out values 

• Local IP address and netmask 

• Gateway address 

• Port Numbers 

• Station Name 

• Local AE Title(s) 

• Remote AE Title(s) 

8. SUPPORT FOR FUTURE ENHANCEMENTS 

Several extensions and modifications to the DICOM standard are being considered. A vendor is 
obviously free to implement any of the new services as they are being specified. However, some of 
them are critical to resolve difficulties that the VA is experiencing, others are necessary extensions 
to the current operation. 

In general, the vendor shall implement extensions to the DICOM standard within 12 months after the 
applicable supplement has been balloted and approved by the DICOM committee members. 
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9.ANNEX 

9.1. Usage Profiles: 

Depending on specific Site and Modality requirements, as specified in the respective profiles, the modality shall support the following Uses: 

Table 10: Optional SOP classes and usage: 


Profile: 

Modality Storage 

Basic 

Print 

Meta 

SOP 

Class 

Patient 
Root Info 
Model 
FIND 

Patient 
Root Info 
Model 
MOVE 

Study 
Root Info 
Model 
FIND 

Study 
Root Info 
Model 
MOVE 

Mod 

Worklist 
Info Model 
FIND 

Storage 

Commitment 

Modality 

Performed 

Procedure 

Step 

Verification 

1 .Basic Core Profile 

scu 






SCU 

SCU 

SCU 

SCU/SCP 

2.Basic Print 

scu 

SCU 





scu 

scu 

scu 

SCU/SCP 

3.Storage User/Provider 







scu 

SCU/SCP 

scu 

SCU/SCP 

4.Query User 

SCU/SCP 


SCU 

SCU 

SCU 

SCU 

scu 

SCU/SCP 

scu 

SCU/SCP 

5.Query User/Provider 

SCU/SCP 


SCU/SCP 

SCU/SCP 

SCU/SCP 

SCU/SCP 

scu 

SCU/SCP 

scu 

SCU/SCP 


9.2. Additional SOP Classes: 

The following Query/Retrieve SOP classes shall be supported when required according to the Profile definition: 


Table 11: Specification of Optional SOP Classes: 


SOP Class Name 

SOP Class UID 

Usage 

Patient Root Query/Retrieve Information model-FIND 

1.2.840.10008.5.1.4.1.2.1.1 

See Table 10 

Patient Root Query/Retrieve Information model-MOVE 

1.2.840.10008.5.1.4.1.2.1.2 

See Table 10 

Study Root Querv/Retrieve Information model-FIND 

1.2.840.10008.5.1.4.1.2.2.1 

See Table 10 

Study Root Query/Retrieve Information model-MOVE 

1.2.840.10008.5.1.4.1.2.2.2 

See Table 10 
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10.APPENDIX - DIFFERENCES BETWEEN THE VA/DOD AND IHE REQUIREMENTS 

There are several reasons for differences between the VA/DOD Requirements Document and the 
IHE Technical Framework Version 3.0. IHE is interested in demonstrating interoperability, while the 
VA and DOD are trying to solve practical problems with operational systems. The IHE document 
makes several implicit assumptions that the VA chose to explicitly state as a requirement in its 
document. 

The Notable differences between this VA/DOD requirement document and the IHE Technical 
Framework are as follows: 

1) The VA absolutely requires valid Patient Name, Patient ID, and Accession Number data in each 
image header. The VA states a minimum length requirement for these fields. The VA requires 
image acquisition modalities to provide a mechanism to allow the technologist to enter this data 
manually, in the event that the Modality Worklist SCP is not accessible. 

The IHE Technical Framework document allows these fields in the image header to have zero 
length, when the Modality Worklist SCP is not available, and furthermore, requires receiving 
systems to be able to handle zero-length values for such attributes. 

These two statements are not inconsistent. The IHE is trying to demonstrate uninterrupted 
functionality during a degraded mode of operation, while the VA is requiring manual intervention 
to fix the same problem. 

2) The DICOM elements Reason for the Study (0032,1030), Reason for the Requested Procedure 
(0040,1002), and Reason for the Imaging Service Request (0040,2001) are all limited to 64 
characters in length by the DICOM Long String Value Representation. 

In the VA and DOD HIS/RIS the reason for the study is often a short patient history 
summarizing the condition of the patient and giving background information for the reason for 
the study, and often exceeds the 64-character length restriction. In order to faithfully 
communicate this essential field, the VA has chosen to map it to the Additional Patient History 
(0010,21 B0) attribute. 

3) The VA has a 1:1 mapping from the Accession Number to the Requested Procedure. IHE 
allows for a more comprehensive 1 :N mapping. 

4) The VA/DOD requirement does not allow for wild card matching in a Modality Worklist query in 
either the Accession Number or Requested Procedure ID elements. 

5) The VA requires that all image acquisition modalities support the Verification SOP Class, both 
as a SCU and a SCP. This is absent from the IHE document, but is a requirement due to the 
Storage Commit role reversal. 

6) The VA explicitly states its Association Acceptance policies, and requirements for the full 
range of port numbers. 

7) The VA states that the Image SOP Instance UID should not change for an image instantiation. 

8) The VA elaborates on the difference between deferred and immediate Storage Commitment, 
and the need for supporting both. 
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9) The Examination Verification process is described in the VA/DOD document. 

10) Modality Worklist Query scenarios for old studies and non-radiology studies are described in 
the VA/DOD document. 

11) The VA emphasizes the requirement for double verification for users of Modality Worklist, since 
in the past it has been so easy to pick the wrong patient/study. 

12) The VA requires images in Explicit VR Little Endian transfer syntax. 


13) The VA states a pixel representation requirement clarifying the usage of MONOCHROME1 and 
MONOCHROME2. 
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